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ABSTRACT 

Users  regularly  experience  a  crisis  of  confidence  on  the  In¬ 
ternet.  Is  that  email  or  instant  message  truly  originating  from 
the  claimed  individual?  Such  doubts  are  commonly  resolved 
through  a  leap  of  faith,  expressing  the  desperation  of  users. 

To  establish  a  secure  basis  for  Internet  communication,  we 
propose  SafeSlinger,  a  system  leveraging  the  proliferation  of 
smartphones  to  enable  people  to  securely  and  privately  ex¬ 
change  their  public  keys.  Through  the  exchanged  authentic 
public  key,  SafeSlinger  establishes  a  secure  channel  offer¬ 
ing  secrecy  and  authenticity,  which  we  use  to  support  secure 
messaging  and  file  exchange.  Essentially,  we  support  an  ab¬ 
straction  to  safely  “sling”  information  from  one  device  to 
another. 1  SafeSlinger  also  provides  an  API  for  importing  ap¬ 
plications’  public  keys  into  a  user’s  contact  information.  By 
slinging  entire  contact  entries  to  others,  we  support  secure 
introductions,  as  the  contact  entry  includes  the  SafeSlinger 
public  keys  as  well  as  other  public  keys  that  were  imported. 
As  a  result,  SafeSlinger  provides  an  easy-to-use  and  under¬ 
stand  approach  for  trust  establishment  among  people. 

1.  INTRODUCTION 

For  many  current  Internet  applications,  users  experience  a 
crisis  of  confidence.  Is  the  email  or  instant  message  we  re¬ 
ceived  from  the  claimed  individual  or  was  it  sent  by  a  spam¬ 
mer? 

Cryptography  alone  cannot  address  this  problem.  We  have 
many  useful  protocols  such  as  SSL  or  PGP  for  entities  that 
already  share  authentic  key  material,  but  the  root  of  the  prob¬ 
lem  still  remains:  how  do  we  obtain  the  authentic  public  key 
from  the  intended  resource  or  individual?  The  global  certifi¬ 
cation  process  for  SSL  is  not  without  drawbacks  and  weak¬ 
nesses  [27,34],  and  the  usability  challenges  of  decentralized 
mechanisms  such  as  PGP  are  well-known  [42], 

The  problem  of  human-oriented,  trust  establishment  is  fun¬ 
damental;  no  amount  of  automation  and  “fail-safe”  defaults 
can  avoid  the  need  for  basic  trust  decisions  to  be  made  by  hu¬ 
mans  (system  administrators  and  ordinary  users  alike),  since 
they  ultimately  assume  the  risks  of  digital  communication, 
accessing  remote  sites,  allowing  remote  access  to  their  local 
resources,  and  employing  other  users’  services. 

1  We  thank  Moxie  Marlinspike  for  suggesting  the  “sling”  metaphor. 


Of  course  ordinary  users  can  extensively  rely  on  system 
administrators’  help  in  making  trust  decisions.  However, 
ordinary  users  inevitably  face  challenging  decisions  alone; 
most  users  at  home,  on  travel,  on  vacation,  or  in  small  busi¬ 
nesses  do  not  benefit  from  skilled  help.  All  this  while  the 
need  and  temptation  to  use  new  online  services  steadily  in¬ 
creases. 

The  human-centric  foundation  of  trust  establishment  makes 
this  problem  universally  important;  protocols  and  interfaces 
need  to  be  designed  for  a  diverse  population  of  varying  skills, 
interests,  ages,  and  cultures.  We  postulate  that  usability  is 
currently  the  major  barrier  for  widespread  adoption  of  cryp¬ 
tography.  We  observe  a  lack  of  well-designed  security  inter¬ 
faces  for  current  information  and  communication  services. 

In  addition  to  usability  concerns,  many  systems  do  not  pro¬ 
vide  the  security  that  they  advertise.  Observing  the  lack  of 
usable  public  key  cryptography  systems,  Tim  Berners-Lee 
has  called  upon  security  researchers  and  professionals  to  de¬ 
sign  a  public  key  encryption  system  for  the  people  [11]. 

The  recent  proliferation  of  smartphones  offers  a  promis¬ 
ing  opportunity  to  address  these  challenges.  Current  smart¬ 
phones  are  highly  sophisticated,  offering  a  general  comput¬ 
ing  environment  with  a  powerful  processor,  high-resolution 
display,  several  communication  modalities  (Bluetooth,  WiFi, 
4G),  camera,  and  sensors. 

Unfortunately,  smartphone  platforms  suffer  from  many  risks. 
Vulnerabilities  exist  in  communication  standards  that  enable 
eavesdropping  or  impersonation  [31,41].  Moreover,  phone 
operators  are  disclosing  information  or  introduce  vulnerabil¬ 
ities  through  insecure  or  misconfigured  systems  [33]. 

We  observe  that  individuals  often  have  physical  interac¬ 
tions  with  resources  or  other  individuals  before  communi¬ 
cating  digitally.  Often,  people  communicate  over  the  Inter¬ 
net  or  via  SMS  after  having  met  in  person.  We  propose  to 
leverage  the  initial  physical  encounter  to  bootstrap  trust,  in 
essence  converting  physical  trust  into  digital  trust.  We  argue 
that  this  is  a  model  that  people  can  intuitively  relate  to. 

Certainly,  many  people  communicate  over  the  Internet  be¬ 
fore  physically  meeting.  To  set  up  trust  for  these  interac¬ 
tions,  we  propose  a  secure  introduction  mechanism  for  trust 
establishment  that  is  rooted  in  physical  encounters  with  a 
common  acquaintance.  For  example,  if  users  could  verify 
that  the  virtual  person  on  a  Facebook  invitation  page  has 
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physically  met  with  one  of  their  close  friends,  they  can  gain 
more  trust  that  the  invitation  page  was  indeed  issued  by  the 
correct  individual. 

In  this  paper,  we  describe  SafeSlinger,  a  system  for  se¬ 
cure  exchange  of  authentic  information  between  two  smart¬ 
phones.  In  essence,  SafeSlinger  exchanges  contact  infor¬ 
mation,  containing  public  keys  in  addition  to  standard  con¬ 
tact  list  information  such  as  name,  picture,  phone  numbers, 
email  addresses,  etc.  Thanks  to  the  association  between  the 
individual  holding  the  phone  and  the  public  key  that  is  ex¬ 
changed,  users  (with  the  help  of  the  SafeSlinger  App)  can 
later  associate  digital  communication  with  the  previously  met 
individual  by  verifying  a  digital  signature.  To  make  Safe¬ 
Slinger  usable,  the  cryptographic  aspects  are  mostly  hidden 
from  the  user.  Achieving  these  goals  while  retaining  the  de¬ 
sired  security  properties  is  far  more  challenging  than  it  ini¬ 
tially  sounds  (Section  4  lists  challenges).  We  have  built-in 
several  approaches  to  make  SafeSlinger  tolerant  to  user  er¬ 
ror,  as  we  describe  in  this  paper. 

We  envision  SafeSlinger  as  a  general  approach  to  boot¬ 
strap  secure  digital  communication.  (1)  First,  we  enable 
small  groups  (2-10  individuals)  of  physically  co-located  users 
to  securely  bootstrap  trust  by  slinging  keys  between  their  de¬ 
vices  (a  one-time  operation).  SafeSlinger  can  also  support 
remote  setup,  as  long  as  users  can  authenticate  the  other  in¬ 
dividual  (e.g.,  via  live  video  conference  or  voice  communi¬ 
cation).  (2)  Second,  we  built-in  secure  phone-to-phone  mes¬ 
saging  and  file  transfer,  both  providing  secrecy  and  authen¬ 
ticity.  The  user  experience  is  nearly  identical  to  that  of  tradi¬ 
tional  SMS  and  MMS  messaging  today.  (3)  Third,  SafeSlin¬ 
ger  enables  secure  introductions  without  physical  meetings 
by  allowing  a  common  acquaintance  to  facilitate  a  mutual 
introduction  enabled  by  SafeSlinger  file  transfer.  (4)  Fourth, 
we  enable  other  applications  to  use  the  SafeSlinger  API  to 
add  their  public  key  to  a  contact  entry.  Now,  when  a  user 
slings  its  updated  contact  list  entry  to  another  user,  the  appli¬ 
cations’  public  key  is  automatically  included,  and  the  same 
application  at  the  other  end  can  extract  the  public  key.  This 
mechanism  can  enable  applications  such  as  secure  email  or 
secure  SMS  to  solve  the  problem  of  securely  exchanging  the 
public  key  without  a  leap  of  faith. 

This  paper  makes  the  following  contributions.  SafeSlin¬ 
ger  is  the  first  complete  system  that  provides  secure  group 
credential  exchange  that  is  also  privacy-preserving,  such  that 
no  external  party  can  learn  any  of  the  exchanged  informa¬ 
tion.  SafeSlinger  is  also  the  first  group  credential  exchange 
system  that  can  be  used  remotely  over  a  telephone  or  video 
conferencing  line.  SafeSlinger  is  designed  to  be  easy-to-use 
and  defend  against  all  attacks  we  are  aware  of.  We  have  im¬ 
plemented  SafeSlinger  on  Android  and  iOS,  and  have  made 
it  freely  available.  SafeSlinger  includes  mechanisms  for  se¬ 
cure  messaging  and  file  exchange,  as  well  as  secure  intro¬ 
duction  between  two  individuals. 

2.  PROBLEM  DEFINITION,  GOALS,  ASSUMP¬ 
TIONS  AND  ADVERSARY  MODEL 


In  this  section,  we  define  the  problem  we  set  out  to  solve, 
discuss  our  goals,  present  assumptions  that  need  to  hold,  and 
the  adversary  that  we  defend  against. 

2.1  Problem  Definition 

The  basic  bootstrapping  primitive  that  we  want  to  accom¬ 
plish  is  to  securely  exchange  information  that  is  associated 
with  the  intended  individuals  participating  in  an  exchange. 
The  security  properties  that  we  seek  are  information  secrecy 
(only  the  intended  entities  receive  the  information),  and  user- 
verifiable  trustworthy  association  of  data  to  an  honest  indi¬ 
vidual  (user  knows  exactly  the  information  that  is  associated 
with  a  specific  honest  individual). 

Note  that  there  are  fundamental  limits  on  the  ability  of  an 
electronic  protocol  to  protect  one  human  against  another  hu¬ 
man  with  the  intent  to  deceive,  hence  the  adjective  “honest”. 
There  are  some  subtleties  involved  when  the  exchange  in¬ 
cludes  more  than  two  people.  For  example,  if  Fred,  George, 
and  Harry  perform  an  exchange,  and  Harry  is  adversarial, 
we  still  wish  for  the  information  exchanged  between  Fred 
and  George  to  have  all  of  its  security  properties  intact.  Intu¬ 
itively,  we  wish  for  the  group  exchange  to  produce  the  exact 
same  security  properties  that  would  result  from  exhaustive 
pairwise  exchanges  between  all  members  of  the  group. 

Given  such  a  secure  exchange  that  includes  a  public  key, 
all  subsequent  mechanisms  for  authentic,  integrity-protected, 
and  optionally  secret  communication  can  be  implemented 
using  well-known  protocols,  relying  on  the  authentic  bind¬ 
ing  of  the  public  key  to  the  correct  individual. 

2.2  Goals 

Our  core  goal  is  to  enable  usability  while  retaining  the  se¬ 
curity  properties  described  in  the  problem  definition.  The 
lack  of  usability  is  likely  to  have  been  a  core  detriment  to 
the  limited  adoption  of  PGP  [42].  Therefore,  we  want  to 
make  SafeSlinger  as  easy  as  possible  to  use.  Unfortunately, 
many  cases  present  a  tradeoff  between  security  and  usability; 
for  example,  requiring  users  to  validate  the  equality  of  hash 
values  during  protocol  execution  is  a  tedious  operation  and 
users  inevitably  select  “equal”  without  performing  the  com¬ 
parison.  In  such  cases,  we  need  to  make  the  system  slightly 
less  usable  and  demand  more  from  the  user  to  retain  a  high 
level  of  security. 

Another  goal  is  to  support  heterogeneous  platforms,  thus 
enabling  interactions  among  smartphones  of  several  manu¬ 
facturers  and  running  different  operating  systems.  This  turns 
out  to  be  a  major  challenge,  since  even  simple  Bluetooth 
communication  is  not  feasible  across  phones  from  different 
vendors,  as  an  Apple  iPhone,  for  example,  only  wishes  to 
communicate  via  Bluetooth  with  another  Apple  product  or 
a  headset.  We  discuss  these  aspects  in  more  detail  in  our 
implementation  section. 

Moreover,  we  want  to  support  several  users  to  simulta¬ 
neously  exchange  their  contact  list  information.  Without 
this  requirement,  it  would  be  tedious  for  a  group  of  users 
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to  exchange  their  information  via  N  •  (N  —  1)  /2  pairwise  ex¬ 
changes. 

2.3  Assumptions 

Our  protocols  do  need  to  assume  certain  user  behaviors 
to  execute  successfully.  First,  we  assume  that  users  are  com¬ 
puter  literate  and  can  follow  basic  instructions,  such  as  “com¬ 
pare  the  words2  presented  on  your  screen  with  the  words  pre¬ 
sented  on  other  phones  and  select  the  ones  that  are  equal”. 
We  also  assume  that  users  have  a  natural  desire  for  security 
and  that  they  do  not  want  to  deliberately  disclose  their  pri¬ 
vate  information.  We  also  assume  that  users  can  authenticate 
(in  the  human  sense,  e.g.,  recognizing  the  other  users’  ap¬ 
pearance,  voice,  etc.)  the  individuals  that  they  perform  infor¬ 
mation  exchanges  with,  such  that  an  adversary  who  imper¬ 
sonates  another  individual  would  be  detected  through  per¬ 
sonal  identification. 

We  also  assume  that  the  smartphone  hardware  and  soft¬ 
ware  is  free  of  vulnerabilities  and  malware,  as  securing  these 
is  out  of  scope  for  this  work. 

2.4  Adversary  Model 

We  assume  that  some  of  the  legitimate  users  that  partic¬ 
ipate  in  the  protocol  may  be  malicious.  (We  call  the  other 
users  honest.)  We  consider  a  Dolev-Yao  style  adversary  that 
has  complete  control  over  all  network  messages.  Further¬ 
more,  any  Internet  server  we  may  use  during  protocol  oper¬ 
ations  may  be  malicious.  We  also  assume  that  adversaries 
may  be  physically  present  in  the  space  where  information 
exchanges  happen. 

We  consider  an  adversary  who  wants  to  break  the  prop¬ 
erties  as  described  in  the  problem  definition,  i.e.,  violate 
secrecy  and  authenticity  properties  of  the  information  ex¬ 
change  and  subsequent  communication.  We  consider  denial- 
of-service  attacks  to  be  out  of  scope,  as  users  can  easily  de¬ 
tect  the  lack  of  progress  of  the  protocol  and  re-start  it  as 
needed. 

3.  CRYPTOGRAPHIC  BACKGROUND 

We  provide  background  on  the  cryptographic  mechanisms 
used  in  this  paper:  multi-value  commitments  and  group  Diffie- 
Hellman  key  agreement. 

3.1  Multi- Value  Commitments 

A  cryptographic  commitment  protocol  is  used  to  lock  an 
entity  to  a  value  V  without  disclosing  V .  Based  on  the  com¬ 
mitment  value,  the  decommitment  can  be  validated  and  the 
protocol  ensures  that  the  correct  value  V  is  disclosed.  A 
commitment  protocol  for  value  V  can  proceed  as  follows: 

C  =  H(V,R),  where  C  is  the  commitment  value,  H  is  a  cryp¬ 
tographic  hash  function  that  is  one-way  and  collision-free, 
and  R  is  a  random  unpredictable  nonce.  Thanks  to  the  prop¬ 
erties  of  the  hash  function  and  the  randomness  of  R,  V  can¬ 
not  be  inferred  from  the  commitment  C.  To  open  the  com¬ 

2Presented  in  the  participants’  common  language,  e.g.,  English. 


mitment,  V  and  R  are  disclosed.  The  collision  resistance 
property  of  H  ensures  that  it  is  computationally  infeasible  to 
find  another  V  or  R  that  will  result  in  the  same  commitment 
C.  Note  that  if  V  is  unpredictable  (e.g.,  a  freshly  generated 
ephemeral  public  key),  the  additional  nonce  value  R  is  not 
needed  and  we  simply  have  C  =  H(V). 

C 

/\ 

HV i  HV2 

t  I 

Vi  V2 

Figure  1:  Multi-value  commitment  structure  for  authen¬ 
ticating  and  disclosing  either  V\  or  V2. 

In  case  we  want  to  commit  to  either  value  Vi  or  V2  (decid¬ 
ing  which  to  actually  release  at  a  future  time)  with  a  single 
commitment,  we  can  employ  a  tree-like  structure  (Figure  1). 
HV\  =  H(V i ),  HV2  =  /-/(  Vi),  and  C  =  H{HV\  \ \  HV2),  where 
||  indicates  the  concatenation  operator.  This  structure  en¬ 
ables  decommitment  of  either  V\  or  V2  without  disclosing 
the  other.  For  example,  to  decommit  V\ ,  we  disclose  V)  and 
H\ 2,  and  the  case  for  V2  is  analogous.  Note  that  this  ex¬ 
ample  is  for  the  case  when  Vi  and  V2  are  unpredictable  to 
the  adversary;  additional  use  of  nonces  is  required  for  well- 
known  V\  or  V2.  This  type  of  structure  is  similar  to  one-time 
signatures  [29]. 

In  our  protocols,  we  further  make  use  of  hierarchical  com¬ 
mitments,  where  the  decommitment  value  is  again  a  commit¬ 
ment  value. 

3.2  Group  Diffie-Hellman  Key  Agreement 

Group  Diffie-Hellman  (DH)  key  agreement  is  a  general¬ 
ization  of  the  two-party  DH  key  agreement  [9],  where  multi¬ 
ple  parties  participate  to  establish  a  common  group  key.  The 
Cliques  protocol  is  an  example  for  group  DH  key  establish¬ 
ment  [37].  We  will  make  use  of  STR  [36],  a  tree-based  group 
DH  protocol,  which  we  briefly  describe  in  this  section. 


ix,gx)  {y,gy) 


Figure  2:  Group  DH  key  agreement  tree  for  3  members 
0 mod  p  operations  omitted  for  clarity).  The  notation  is 
(priv,  pub),  where  the  first  element  in  the  parenthesis  lists 
the  DH  private  key,  and  the  second  lists  the  DH  public 
key.  The  group  key  is  the  private  key  K  at  the  root. 

In  group  DH  protocols,  each  participant  is  placed  at  a  leaf 
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node  of  a  binary  tree,  where  each  node  of  the  tree  has  a 
private  and  a  public  key  associated  with  it.  The  value  of 
a  leaf  node  is  the  private  and  public  DH  keys  of  the  mem¬ 
ber  at  that  node.  The  value  of  the  parent  node  is  derived 
through  the  DH  operation  on  the  values  of  the  two  child 
nodes,  for  example  if  the  values  of  the  child  nodes  are  x 
for  the  private  and  gx  mod  p  for  the  public  key  of  the  left 
child,  and  y  for  the  private  and  gy  mod  p  for  the  public  key 
of  the  right  child,  the  parent  value  is  gxy  mod  p  for  the  pri¬ 
vate  and  gy':'  mot*  p  mod  p  for  the  public  value.  Figure  2 
illustrates  a  group  DH  key  agreement  with  three  members, 
where  each  node  in  the  tree  lists  the  private  and  public  DH 
keys.  The  private  key  that  corresponds  to  the  root  node  is 
the  shared  secret  of  all  group  members.  In  the  STR  [36]  pro¬ 
tocol,  the  tree  shape  is  a  maximally  unbalanced  tree  (resem¬ 
bling  a  comb),  and  the  TGDH  [16]  protocol  uses  a  balanced 
tree.  Research  has  shown  that  total  protocol  latencies  are 
lower  for  STR  in  environments  where  the  communication 
latency  dominates  over  the  computation  of  a  modular  expo¬ 
nentiation  [15],  which  is  the  case  in  mobile  environments. 

4.  ATTACKS  AND  CHALLENGES 

Secure  local  exchange  of  information  is  a  surprisingly  in¬ 
tricate  and  challenging  problem.  Numerous  attacks  are  pos¬ 
sible,  which  we  will  illustrate  with  two  simple  protocols.  We 
then  discuss  the  attacks  in  more  detail. 

4.1  Strawman  Approaches 

We  consider  two  simple  protocols  for  local  authenticated 
and  secret  exchange  of  information  between  users  who  are 
physically  nearby  each  other  and  who  want  to  simultane¬ 
ously  exchange  their  contact  list  information,  which  also 
contains  their  public  key. 

Password-based  exchange. 

In  this  protocol,  a  password  shared  among  users  is  used 
to  secure  the  information  exchange.  Several  researchers  pro¬ 
posed  protocols  of  this  flavor,  for  example  Asokan  and  Ginz- 
boorg  [2],  Valkonen,  Asokan  and  Nyberg  [39],  and  Abdalla 
etal.  [1], 

A  simplified  password-based  protocol  proceeds  as  follows: 
the  users  agree  on  a  password  P  and  enter  it  into  their  de¬ 
vices.  From  P,  the  devices  derive  a  symmetric  key  with  a 
cryptographic  hash  function  H  (i.e.,  K  =  H(P)),  and  K  is 
used  to  encrypt  and  authenticate  their  communication.  Each 
user  broadcasts  its  information  to  the  others  as  follows  (where 
lx  represents  the  information  of  user  X,  and  MAC  represents 
a  secure  message  authentication  code,  and  {X}k  stands  for 
encryption  of  message  X  with  key  K): 

({ Ia}k ,  MAC*({/a}*)) 

B  — >  *  :  {{Ib}k,  MAC^({/b}a:)) 

C^*:  ({/c}*,  MACjc({/c}*)> 

D  — >  *  :  ({Id}k,  MACk({Id}k)} 

Each  user  then  uses  their  key  K  to  authenticate  and  de¬ 
crypt  the  received  information.  Unfortunately,  this  approach 
is  vulnerable  to  several  attacks.  First,  a  malicious  bystander 


could  overhear  or  guess  the  password,  and  control  communi¬ 
cation  such  that  the  legitimate  users’  messages  do  not  reach 
the  receivers,  while  the  attacker  is  able  to  insert  information 
of  his  choosing.  In  the  Dolev-Yao  attacker  model,  where 
the  attacker  controls  all  communication,  this  is  a  simple  at¬ 
tack.  In  practice,  it  is  quite  possible  to  mount  such  an  attack. 
Especially  in  the  case  of  wireless  communication,  the  adver¬ 
sary  can  jam  legitimate  messages  to  prevent  reception,  and 
then  re-insert  messages  that  will  be  received  by  the  receivers. 
Note  that  this  weakness  stems  in  part  from  the  password- 
based  key  exchange  protocol’s  requirement  that  the  pass¬ 
word  be  kept  secret  from  all  non-participants. 

Second,  a  malicious  participant  (as  opposed  to  a  bystander) 
could  easily  mount  this  attack  as  well,  since  that  user  will 
know  the  password.  Such  a  malicious  user  could  control  all 
the  information  that  each  member  receives.  Note  the  distinc¬ 
tion  between  a  malicious  user’s  being  able  to  misrepresent 
his  own  identity  (which  simplifies  to  a  problem  with  human 
trust,  and  cannot  be  solved  with  a  protocol  to  the  best  of 
our  knowledge),  and  that  user’s  being  able  to  insert  fraud¬ 
ulent  information  for  honest  protocol  participants  (which  is 
a  protocol  weakness).  This  represents  the  protocol  placing 
excessive  trust  in  a  single  participant. 

Both  attacks  are  instances  of  Man-in-the-Middle  (MitM) 
attacks,  which  are  a  common  form  of  protocol  attacks. 

Group  Diffie-Hellman  with  Key  Comparison. 

A  promising  approach  to  eliminate  the  requirement  that 
human  protocol  participants  communicate  amongst  them¬ 
selves  secretly  is  to  leverage  a  group  Diffie-Hellman  (DH) 
key  establishment  protocol  (Section  3.2).  MitM  attacks  can 
be  prevented  by  human  verification  of  equality  of  the  estab¬ 
lished  key  among  the  participants.  A  sample  comparison- 
based  protocol  is  by  Valkonen,  Asokan  and  Nyberg  [39]. 

The  idea  in  comparison-based  DH  key  establishment  is  to 
detect  MitM  attacks  by  having  the  users  visually  compare  a 
hash  of  the  shared  secret  that  results  at  the  end  of  the  DH 
protocol.  To  understand  this  defense,  consider  the  following 
exchange  between  two  users  X  and  Y.  X  has  the  private  DH 
key  x,  and  Y  has  private  key  y.  Following  a  successful  key 
agreement,  they  would  share  the  key  Kxy  =  gxy  mod  p.  If 
the  users  compare  a  few  bits  of  H(Kxy),  where  H  is  a  cryp¬ 
tographic  hash  function,  they  try  to  ensure  that  they  have  the 
same  key.  Since  H  is  a  one-way  function,  this  comparison 
does  not  reveal  the  secret  key.  A  variety  of  approaches  exist 
to  compare  these  keys,  ranging  from  hexadecimal  represen¬ 
tations  of  the  hash  to  hash  functions  with  pictures  as  output 
to  simplify  comparison  [14].  If  the  comparison  suggests  that 
the  keys  are  equal,  the  users  inform  the  application  to  pro¬ 
ceed. 

In  case  of  a  MitM  attack,  where  an  adversary  M  imper¬ 
sonates  X  to  Y  and  Y  to  X,  M  would  have  sent  gm 1  mod  p 
to  X  and  gm2  mod  p  to  Y.  Consequently,  X  computes  the 
secret  key  gx  ml  mod  p  and  Y  computes  gy  m2  mod  p.  Since 
the  two  keys  are  different,  the  hash  values  will  also  be  dif¬ 
ferent  between  Y’s  and  T’s  device  with  high  probability  and 
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the  attack  would  be  detected. 

Unfortunately,  numerous  attacks  are  possible.  First,  most 
users  prefer  convenience  over  security,  and  they  may  sim¬ 
ply  select  “OK,  hash  is  equal”  without  performing  the  actual 
comparison.  Since  no  attack  occurs  most  of  the  time,  the 
users  would  also  lose  interest  to  perform  such  a  comparison. 
Another  issue  is  the  entropy  of  the  values  that  are  compared: 
to  make  this  comparison  more  usable,  only  a  subset  of  the 
full  160-bit  hash  of  a  SHA-1  hash  function  would  be  pre¬ 
sented  to  the  user,  as  the  full-length  comparison  is  too  time 
intensive.  Consequently,  users  may  only  compare  about  20 
bits,  with  the  idea  that  an  attack  would  be  caught  with  proba¬ 
bility  of  1  —  1  /220,  which  means  that  only  about  one  in  a  mil¬ 
lion  attacks  would  go  unnoticed  and  be  successful  (assum¬ 
ing  users  indeed  perform  the  comparison).  Unfortunately, 
another  attack  is  possible  on  comparisons  with  limited  en¬ 
tropy.  The  MitM  adversary  can  compute  ml  and  m2  such 
that  [H(gxml  mod  p)]2o  =  [H(gy  m2  mod  p)\2o,  where  [.]20 
indicates  truncation  down  to  the  least  significant  20  bits.  Be¬ 
cause  the  attacker  controls  both  sides  of  the  equation,  find¬ 
ing  a  collision  can  exploit  the  birthday  paradox  and  the  ex¬ 
pected  number  of  operations  to  find  the  collision  is  0( 210), 
requiring  only  around  1000  cryptographic  operations,  which 
is  trivial  to  accomplish  on  current  hardware  (e.g.,  by  out¬ 
sourcing  computations  to  a  cloud). 

Yet  another  attack  on  this  protocol  for  groups  of  three  or 
more  participants  is  that  a  bystander  could  participate  in  the 
protocol  -  the  invisible  nature  of  electronic  communication 
prevents  humans  from  observing  which  devices  are  actually 
communicating.  Consequently,  the  adversary  could  learn 
the  shared  secret,  and  of  course  all  hash  comparisons  will 
be  successful,  as  all  members  share  the  same  group  secret 
key!  The  problem  is  that  the  additional  member  is  difficult 
to  detect.  A  simple  countermeasure  against  this  attack  is 
to  require  members  to  count  and  verify  the  number  of  le¬ 
gitimate  group  members.  Unfortunately,  as  prior  research 
shows,  counting  is  unreliable  when  the  number  of  group 
members  is  larger  than  8,  as  people  tend  to  make  mistakes 
causing  the  protocol  to  fail  [8].  Moreover,  another  attack  is 
possible  even  if  members  could  count  correctly:  the  Group- 
in-the -Middle  (GitM)  attack  [17]. 

In  a  GitM  attack,  a  group  member  participating  in  the  pro¬ 
tocol  is  malicious  and  exploits  the  invisibility  of  wireless 
communication  to  split  the  group  into  several  subgroups, 
adding  additional  virtual  users  to  create  the  illusion  to  each 
member  that  they  are  in  a  group  with  the  correct  number  of 
users.  For  instance,  consider  a  group  with  4  members  A,B,C 
and  D,  who  attempt  to  run  the  protocol.  Consider  that  D  is 
malicious,  so  he  could  create  virtual  identities  X,Y,  and  Z, 
and  since  he  controls  the  wireless  signals  and  their  reception 
through  careful  jamming  and  directional  antennas,  he  can 
create  the  illusion  of  two  groups:  A,B,X,D,  and  Y,Z,C,D. 
Note  that  the  legitimate  members  A .  B.  and  C  cannot  detect 
this  attack,  since  they  believe  that  they  are  performing  the 
protocol  in  a  group  with  4  users.  Similar  to  the  2-party 
MitM  collision  attack  discussed  above,  D  can  select  the  pri¬ 


vate  keys  for  X,Y,Z,  and  D  such  that  the  two  subgroups  will 
end  up  with  the  same  hash  to  compare,  preventing  the  mem¬ 
bers  A,B,C  from  detecting  the  attack  even  if  they  diligently 
check  all  the  hashes. 

We  hope  that  these  two  strawman  protocols  demonstrate 
that  designing  a  usable  and  secure  information  exchange  pro¬ 
tocol  is  a  surprisingly  intricate  challenge.  Next,  we  give  a 
more  thorough  list  of  attacks  and  challenges. 

4.2  List  of  Attacks  and  Challenges 

We  consider  the  following  attacks: 

•  Malicious  bystander  who  participates  in  protocol: 

a  bystander  can  overhear  conversation,  and  attack  the 
protocol  by  controlling  the  local  wireless  communi¬ 
cation  (Dolev-Yao  attacker  model).  The  Man-in-the- 
Middle  (MitM)  attack  is  a  specific  instance  of  this 
attack. 

•  Malicious  group  member:  an  invited  member  of  the 
group  wants  to  violate  protocol  properties,  such  as  mount¬ 
ing  an  impersonation  attack  by  injecting  incorrect  in¬ 
formation  for  another  user,  or  performing  a  Sybil  at¬ 
tack  [10]  by  injecting  multiple  entries  either  for  ficti¬ 
tious  individuals  or  for  individuals  who  are  not  present. 

A  malicious  group  member  can  also  perform  a  Group- 
in-the-Middle  (GitM)  attack  [17],  as  described  above. 

•  Malicious  server:  for  protocols  that  rely  on  a  back¬ 
end  server,  the  server  may  be  controlled  by  a  malicious 
administrator  or  be  compromised  and  thus  execute  ma¬ 
licious  code. 

•  Information  leakage  after  protocol  abort:  an  adver¬ 
sary  may  be  able  to  cause  a  protocol  abort  and  trigger 
information  leakage  of  private  information  about  a  par¬ 
ticipant. 

•  Collision  attack  on  low-entropy  hash:  as  described 
above,  low-entropy  hash  values  can  be  vulnerable  to 
efficient  birthday  attacks  if  the  correct  precautions  are 
not  taken. 

We  consider  the  following  challenges: 

•  Exclusion  of  unintended  participants:  legitimate  users 
will  expel  an  unwanted  bystander  who  wants  to  partic¬ 
ipate  in  the  protocol. 

•  Correct  member  count:  users  need  to  correctly  count 
number  of  group  members. 

•  Identity  validation:  users  correctly  validate  the  iden¬ 
tity  of  information  received  from  the  exchange.  More 
specifically,  they  map  the  identity  information  to  the 
people  who  are  physically  present,  and  they  would  re¬ 
ject  information  about  a  person  who  is  not  physically 
present. 

•  Impersonation  detection:  users  verify  that  no  other 
user  has  injected  information  that  impersonates  them 
in  the  current  exchange.  For  example,  a  malicious  user 
may  also  inject  information  about  Alice,  even  though 
Alice  is  also  participating  in  the  exchange.  The  risk  is 
that  another  user  may  discard  the  correct  information 
and  accept  the  wrong  information. 
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•  Diligent  hash  comparison:  users  correctly  perform 
the  hash  comparison,  even  after  executing  the  protocol 
numerous  times  without  any  attack. 

•  Diligent  error  checking  and  aborting:  users  will  abort 
the  protocol  and  restart  the  protocol  when  suspicious  or 
error  conditions  are  encountered. 

In  the  next  section,  we  describe  our  approach  for  design¬ 
ing  SafeSlinger  to  prevent  all  attacks  and  overcome  the  chal¬ 
lenges  listed. 

5.  SAFESLINGER 

In  this  section,  we  provide  a  detailed  description  of  the 
SafeSlinger  protocol.  We  first  provide  a  high-level  overview 
before  we  dive  into  the  details. 

5.1  Overview 

The  main  purpose  of  SafeSlinger  is  to  enable  a  set  of  users 
to  exchange  their  contact  information  such  that  every  non- 
malicious  user  receives  the  correct  information  about  every 
other  non-malicious  user.  Malicious  users  may  collude  and 
impersonate  each  other,  for  example,  therefore  we  cannot 
provide  any  guarantees  for  those  parties.  Our  main  goal  is 
provide  high  usability  while  preventing  the  attacks  we  de¬ 
scribe  in  Section  4. 

The  first  hurdle  we  need  to  overcome  is  to  enable  commu¬ 
nication  among  the  users’  mobile  devices.  To  capture  most 
of  the  market  share  of  current  smartphones,  we  target  An¬ 
droid,  iPhone,  and  Windows  Mobile  devices.  Unfortunately, 
these  platforms  do  not  offer  native  support  for  802.11  ad- 
hoc  mode  or  setup  of  a  base  station  to  enable  other  devices 
to  connect  to  them.  Bluetooth  communication  is  also  chal¬ 
lenging  because  of  the  slow  discovery  phase  and  the  unwill¬ 
ingness  of  iPhones  to  communicate  to  a  non-Apple  device 
except  a  headset.  NFC  is  not  yet  widely  deployed,  and  such 
communication  does  not  scale  to  multiple  devices.  As  a 
consequence,  we  use  Internet-based  communication,  where 
all  the  mobile  devices  connect  to  a  cloud  server.  This  ap¬ 
proach  has  the  additional  advantage  that  no  device  discov¬ 
ery  is  needed,  as  the  devices  can  simply  send  packets  to  the 
server  via  IP. 

We  support  groups  of  up  to  50  users,  however,  we  use  two 
different  protocols:  the  main  SafeSlinger  protocol  which  we 
describe  in  this  paper  for  up  to  7  users,  and  the  Ho-Po  Key 
protocol  for  groups  of  more  than  7  users  [30].  As  prior  work 
shows,  users  can  reliably  count  the  number  of  participants 
for  groups  of  up  to  8  users,  but  several  people  start  to  make 
errors  for  larger  groups  [8],  As  the  protocol  fails  if  only  a 
single  person  miscounts,  we  conservatively  set  the  threshold 
at  7  users,  up  to  which  users  can  reliably  count.  Asking  users 
to  count  the  number  of  participants  rules  out  several  attacks, 
as  we  discuss  in  our  Section  5.4. 

After  the  mobile  devices  connect  to  the  server,  the  server 
cannot  know  which  devices  belong  to  the  same  group.  It  is 
a  challenging  problem  for  the  server  to  determine  the  group¬ 
ing,  especially  if  several  concurrent  exchanges  are  ongoing. 
Several  approaches  exist,  which  we  discuss  in  Section  5.5. 


We  propose  the  following  approach,  which  does  not  leak  any 
sensitive  information  to  our  untrusted  server.  The  server  as¬ 
signs  a  unique  ID  to  each  mobile  device,  which  it  displays 
to  its  user.  The  devices  ask  the  users  to  find  and  enter  the 
lowest  ID.  The  devices  then  send  that  ID  back  to  the  server, 
which  can  thus  perform  the  grouping.  Note  that  the  actual 
grouping  is  not  security  sensitive,  as  an  intruder  will  result 
in  denial  of  service. 

In  a  nutshell,  the  mobile  devices  send  their  information 
to  the  server,  which  redistributes  it  to  the  other  devices.  The 
users  engage  in  a  verification  of  all  exchanged  information  to 
ensure  that  they  all  have  received  identical  information  from 
the  server.  This  verification  is  done  by  the  users  who  perform 
a  comparison  of  short  hash  values  displayed  by  the  phones. 
Two  problems  that  we  discussed  in  Section  4  occur:  (1)  users 
simply  click  “OK”  without  performing  the  comparison,  and 
(2)  an  attacker  can  compute  a  collision  attack  on  the  short 
hash  value.  We  solve  (1)  by  presenting  2  decoy  hash  values 
besides  the  correct  value  and  asking  users  to  verify  which  of 
the  3  hash  values  matches  a  value  on  other  people’s  devices. 
This  forces  the  user  to  perform  the  comparison,  as  a  random 
guess  will  cause  the  protocol  to  fail  2/3  of  the  time.  More¬ 
over,  this  approach  encourages  users  to  select  “no  match”  if 
they  cannot  find  a  match.  We  address  problem  (2)  by  us¬ 
ing  Short  Authentication  Strings  (SAS)  [6,  18,  19,40,43]. 
In  SAS,  all  devices  first  commit  to  the  values  that  are  used 
in  the  hash  comparison.  Once  all  the  commitments  are  dis¬ 
tributed,  the  devices  reveal  the  decommitments  and  the  short 
hash  comparison  can  proceed.  This  approach  prevents  the 
collision  attack  and  in  Zimmermann’s  words  [43]  converts 
the  attack  from  a  “safe  attack”  into  a  “daring  attack.”  The 
collision  attack  is  a  safe  attack,  because  the  adversary  knows 
that  the  attack  will  succeed  with  probability  1  as  the  colli¬ 
sion  has  been  found.  However,  with  the  commitment,  the 
adversary  cannot  know  ahead  of  time  if  the  collision  indeed 
will  occur,  and  the  attack  only  succeeds  with  a  probability 
of  2~n,  where  n  denotes  the  bit  length  of  the  authentication 
string,  thus  resulting  in  a  “daring  attack.” 

A  major  challenge  which  we  address  in  SafeSlinger  is  to 
prevent  the  server  from  learning  any  contact  information. 
We  accomplish  this  by  leveraging  a  group  DH  protocol,  which 
is  described  in  Section  3.2.  The  group  DH  protocol  estab¬ 
lishes  a  shared  secret  key  among  all  participants,  which  is 
used  to  encrypt  the  contact  information.  To  prevent  MitM 
attacks,  the  DH  public  key  is  included  in  the  initial  commit¬ 
ment,  which  the  users  validate  through  the  hash  comparison, 
authenticity  providing  of  the  DH  public  keys. 

5.2  SafeSlinger  Details 

Figure  3  describes  the  SafeSlinger  protocol  in  detail.  In 
Step  1  (which  we  will  abbreviate  as  SI  for  short),  the  user 
selects  which  data  to  share  and  enters  the  total  number  of 
protocol  participants.  In  S2,  the  device  computes  the  val¬ 
ues  needed  for  the  group  DH  protocol  by  selecting  the  £'-bit 
long  DH  private  key  ri,  at  random  (in  the  current  version,  we 
use  £'  =  512).  The  device  also  randomly  selects  nonces  to 
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indicate  “match’'  (Nonce  match  Nmi)  and  “wrong”  (Nonce 
wrong  Nwj).  The  device  also  encrypts  the  data  to  share  with 
the  Nonce  match  used  as  a  symmetric  encryption  key  (we 
use  the  AES  block  cipher  with  128-bit  keys).  In  the  current 
version,  the  security  parameter  t  =  128,  and  we  use  SHA-1 
truncated  to  128  bits  as  hash  function  H.  Figure  4  depicts 
this  multi-value  commitment  structure  for  user  t/,.  Finally, 
in  S3  the  device  sends  the  commitment  C,  to  the  server. 

In  the  next  phase,  the  server  groups  the  users.  First,  the 
server  sends  a  unique  ID  to  the  device  (S4)  which  the  device 
displays  and  prompts  the  user  to  find  the  lowest  ID  amongst 
all  devices  (S5).  In  S6,  the  user  enters  the  lowest  ID  which 
in  S7  the  device  sends  to  the  server. 

The  server  now  knows  which  devices  belong  to  the  same 
group,  and  distributes  ID  and  commitment  pairs  (/£),,  C,)  to 
all  group  members  (S8).  Once  a  device  receives  all  com¬ 
mitments,  in  S9  it  opens  up  the  first  level  decommitment 
HNj,Gi,Ej  (Figure  4  illustrates  this).  If  validation  of  all  de- 
commitments  is  correct  (S10),  devices  compute  a  hash  over 
all  decommitments  of  C;,  i.e.,  over  the  triplets  (fflV*,G*,£*), 
sorted  by  the  value  of  the  unique  7D,  assigned  to  each  device 
to  ensure  that  all  devices  compute  the  hash  over  the  same 
triplet  ordering.  Each  device  then  computes  a  word  phrase 
that  represents  the  hash  (S 1 1)  -  we  use  the  PGP  word  phrase 
which  results  in  a  representation  that  encodes  24  bits  of  the 
hash.  The  device  also  produces  two  decoy  word  phrases, 
which  produces  two  interesting  challenges:  (1)  if  the  words 
in  the  decoy  word  phrase  match  words  in  the  actual  word 
phrase,  users  may  get  confused,  and  (2)  if  words  in  differ¬ 
ent  users’  decoy  word  phrase  match,  users  may  select  the 
wrong  decoy  phrase  on  their  respective  devices  as  a  match. 
To  avoid  this,  we  make  sure  that  the  decoy  phrases  do  not 
include  any  words  from  the  actual  word  phrase,  and  we  also 
make  sure  that  all  decoy  word  phrases  are  mutually  exclu¬ 
sive  among  all  devices,  which  is  a  challenge  to  implement. 
We  address  this  by  using  the  received  commitments  as  a  seed 
to  a  pseudo-random  generator,  and  having  each  device  draw 
words  from  the  word  phrase  for  their  decoy  phrases  with¬ 
out  replacement.  Since  the  word  phrase  only  contains  512 
words  in  total,  this  limits  the  total  number  of  users  we  can 
support.  More  intricate  details  on  the  word  phrase  selection 
are  presented  in  Section  6. 

If  no  phrase  matches,  the  user  selects  “no  match”  and 
sends  the  “wrong”  nonce  Nwj  along  with  Hm]  to  enable  ver¬ 
ification  to  the  server  (S12).  This  case  is  also  triggered  if  the 
user  selects  the  wrong  word  phrase.  This  approach  cryp¬ 
tographically  authenticates  the  “no  match”  message  from 
the  commitment  C,  and  thus  prevents  injection  of  the  wrong 
nonce  by  an  adversary.  In  S13,  users  correctly  selected  the 
matching  word  phrase,  and  the  device  reveals  the  pair  of 
values  indicating  success  ( Hmj,H\Vj ),  which  the  server  re¬ 
distributes  in  S14.  Each  device  can  verify  that  all  the  users 
selected  the  correct  word  phrase  (S15)  and  in  S16  the  de¬ 
vices  proceed  to  construct  the  group  DH  tree  as  described  in 
Section  3.2.  The  ordering  in  the  tree  is  determined  by  the 
sorted  order  of  the  unique  IDs  IDL.  Since  the  STR  group 
DH  protocol  we  use  is  intricate  we  omit  the  details  for  en¬ 


hanced  readability,  but  we  refer  readers  to  the  description  in 
Section  3.2  and  for  more  details  to  papers  on  STR  [15, 36]. 


Data  Selection  &  Counting 

1  TT  UI  TU, 

1.  Uj — >Mj 

:  D[  (the  data  to  be  exchanged) 

T  T  U I  it  4 

Uj — >M,- 

:  Nj  (number  of  people  in  the  group) 

Commitment,  Group  DH  Key  Setup 

2.  Mj 

:  Nnii* — {0, 1}^  (“match”  nonce) 

Hm.i  —  H(Nm,i),  Hm'j  —  H(Hmi) 

Nwi< — {0, 1}^,  Hwi  =  H(N\Vi)  (“wrong”  nonce) 
HNj  —  H (Hm'jWHwi)  (multi-value  commitment) 
1}^,  Gi  —  gn‘  mod  p  (group  DH  key) 

Ei  —  {Di}fifm.  (encryption  of  data) 

Cj  =H(HNi  ||  Gj  Ej)  (commitment) 

3.  Mj~*S 

:  Ci,Ni 

Server  Unique  ID  Assignment,  User  Grouping 

4. 

:  IDj  (unique  ID  per  user) 

5.  Ui 

:  find  lowest  unique  ID  — >  IDi 

6.  Uj^Mi 

:  IDl  (enter  lowest  ID) 

1.  Mi  — >  S 

■  IDl 

Collection  and  Distribution  of  Initial  Decommitment 

8.  S^Mi 

:  IDj,Cj  (j  7^  i)  (other  users’  ID  and  commitment) 

9.  Mi  — >  S 

:  IIV.d  .E 

S  — >  Mi 

:  HNj,Gj,Ej  ( j  ^  i )  (other  users’  decommitment) 

10.  Mi 

:  Cj=H(HNj\\Gj\\Ej)  ( j  +  i)  (verify) 

Wordlist-based  Comparison  of  Integrity  of  Commitments 

11  .Mj 

:  WordPhrase(  [//({(HN*,G*,2i*)})]24)  (screen) 

T  T  U I  .  m 

Ui — >M,- 

:  Select  Matching  Word  Phrase 

12.  Mi  — >  S 

:  Hm'jiNwi,  if  “no  match”  or  wrong  phrase  selected 
Abort  protocol. 

13.  Mj  — >  S 

:  Hmt,Hwi,  if  “match”  &  correct  phrase  selected 

14.  S  — >  Mj 

:  Hmj,Hwj  (j^i) 

15  .Mi 

:  HNj =H (H(Hmj)\\Hwj)  (j  /  i)  (verify) 

Abort  if  any  verification  failed 

Group  DH  Key  Establishment 

16.  Mi 

:  Computation  of  group  DH  tree  (Section  3.2) 

K  =  Private  key  of  root  node  (see  Section  3.2) 

Distribution  and  Verification  of  Data  Decryption  Key 

17.  Mi  ->  S 

:  {Nmi}! ■( 

S  — >  Mi 

:  {Nmj  }K  O'yG) 

18.  Mi 

:  Decryption  of  Nrrij  ( j  ^  i ) 

Hmj=H(Nmj )  (j  ^  ()  (verify) 

Decryption  of  Data  and  User  Acquisition 

19.  Mi 

:  Decryption  of  Ej  with  Nrrij  ( j  ^  i )  — ►  Dj 

Save  user  data  Dj 

Figure  3:  Steps  for  user  t/,  (t  G  1 ... IV)  to  exchange  data 
Dj  with  the  other  N  —  1  users  via  their  mobile  devices. 
6',—vW,  indicates  input  by  user  17, ■  into  mobile  device  Mj. 
Mi  — ►  S  represents  wireless  communication  from  mobile 
device  M,  to  server  S.  {X  }K  represents  encryption  of  X 
with  symmetric  key  K. 

Once  the  secret  group  key  K  is  established,  the  devices 
then  proceed  to  send  their  final  match  nonce  Nirij  (which 
also  serves  as  the  decryption  key)  to  the  group,  encrypted 
with  K  (S17).  In  S18,  each  device  decrypts  and  verifies  the 
correctness  of  Nrrij,  and  finally  uses  Nmi  to  decrypt  the  data 
Dj  in  S 19. 

5.3  User  Experience 

Although  the  protocol  appears  quite  complex  to  achieve 
all  the  security  properties  we  set  out  for,  the  user  experience 
is  actually  quite  simple  as  SafeSlinger  performs  all  the  cryp- 
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r — t — , 

HNt  Gi  =  G"'  mod  p  {A  }iVm, 

/\ 


Hm] 

A 

Hw, 

A 

T 

Hnij 

A 

T 

Nw, 

T 

Nnii 

Figure  4:  Multi-value  commitment  structure  for  user  I/,-. 
Ci,  HNi,  Hm\,  Hwi,  Hm\,  Nwi,  Nmt,  are  160-bit  values;  Gj 
is  512  bits,  and  D,  varies  in  length. 

tographic  operations  and  checks  without  the  users’  involve¬ 
ment.  The  user  experiences  the  following  steps:  (1)  select 
the  data  items  to  be  shared,  (2)  count  and  select  the  number 
of  users,  (3)  find  and  enter  the  lowest  ID  displayed  by  the  de¬ 
vices,  (4)  compare  the  word  phrases  and  select  the  one  that 
matches  and  click  “match”,  or  click  on  “no  match”,  (5)  se¬ 
lect  which  users’  data  to  import  into  ones  contact  list.  We 
optimized  the  implementation  such  that  a  complete  run  only 
requires  on  the  order  of  10  seconds. 

5.4  Security  Analysis 

We  will  use  the  list  of  attacks  and  challenges  from  Sec¬ 
tion  4.2  to  guide  this  security  analysis,  however,  we  con¬ 
sider  additional  attacks  that  are  specific  to  the  operations  of 
the  SafeSlinger  protocol.  We  consider  attacks  on  the  Safe- 
Slinger  protocol  for  groups  of  fewer  than  8  members  that  we 
describe  in  this  paper,  for  the  security  analysis  of  the  proto¬ 
col  with  more  than  8  members  we  refer  to  the  Ho-Po  Key 
paper  [30]. 

We  first  consider  attacks  by  malicious  outsiders  (who  are 
not  legitimate  group  members).  Such  adversaries  can  con¬ 
tact  the  server,  ask  for  a  unique  ID,  and  attempt  to  join  ar¬ 
bitrary  groups  by  sending  the  server  a  plausible  group  ID  to 
join.  Since  users  specify  the  group  size,  this  attack  will  be 
detected  as  the  server  will  send  too  many  commitments  to 
the  participants. 

A  more  sophisticated  version  of  that  attack  is  where  a  lo¬ 
cal  adversary  jams  communication  of  one  of  the  local  de¬ 
vices,  and  attempt  to  join  the  group  that  way.  In  that  case,  the 
local  user  who  is  being  suppressed  by  the  adversary  needs  to 
inform  the  other  group  members  to  abort  the  protocol,  since 
she  is  not  receiving  commitments.  If  the  user  is  receiving 
other  users’  commitments,  then  the  hash  comparison  will 
fail  with  high  probability  (1  —  224)  and  at  least  one  other 
user  who  is  part  of  the  group  needs  to  be  informed  not  to 
press  “match”.  Preventing  this  attack  requires  some  amount 
of  user  diligence,  essentially  the  suppressed  user  has  to  in¬ 
form  at  least  one  honest  group  member  to  select  “no  match” 


in  the  word  phrase  comparison.  Thus,  the  users  need  to  en¬ 
sure  that  they  perform  the  hash  comparison  with  all  other 
users,  fortunately,  as  long  as  at  least  one  user  who  was  not 
suppressed  is  diligent,  then  these  attacks  will  be  detected. 

A  malicious  legitimate  participant  of  the  group  could  at¬ 
tempt  several  attacks.  First,  attempts  to  infiltrate  additional 
virtual  members  into  the  group,  for  example  through  a  Sybil  [10] 
attack,  would  fail  because  the  number  of  virtual  members 
would  be  larger  than  the  count  of  physical  members  which 
users  enter  at  the  beginning  of  the  protocol.  A  Group-in- 
the-Middle  (GitM)  attack  as  described  in  Section  4  is  pre¬ 
vented  if  users  diligently  perform  the  hash  comparison  step, 
as  members  who  end  up  in  different  groups  will  have  differ¬ 
ent  hashes  to  compare  with  high  probability.  The  adversary 
could  also  send  wrong  contact  information  for  himself,  for 
example  attempting  to  impersonate  another  person  who  is 
currently  in  the  group.  SafeSlinger  defends  against  this  at¬ 
tack  by  enabling  users  to  verify  at  the  end  of  the  protocol 
which  contact  phrase  entries  they  import  into  their  address 
book,  and  if  a  suspicious  entry  exists  the  user  can  attribute 
that  to  the  adversary.  If  the  adversary  impersonates  a  user 
who  is  present,  that  user  can  detect  that  someone  else  in¬ 
jected  an  entry  for  herself  and  inform  the  others. 

A  malicious  server  could  try  to  split  the  group  up  into  dif¬ 
ferent  subsets  of  users,  and  fake  another  set  of  users  (GitM) 
to  ensure  that  each  user  encounters  the  correct  number  of 
users,  even  though  some  are  virtual  users  created  by  the 
server.  Again,  diligent  checking  of  the  hash  with  all  other 
members  in  the  group  will  detect  this  attack.  The  server  also 
does  not  learn  any  information  about  the  users,  as  it  cannot 
participate  in  the  group  DH  protocol  to  discover  the  estab¬ 
lished  group  key  K.  The  only  way  to  obtain  K  is  to  par¬ 
ticipate  as  a  user  and  inject  a  commitment,  which  would  be 
detected  by  the  device  as  the  number  of  members  is  larger 
than  the  user  entered. 

The  multi-commitment  with  several  stages  of  decommit¬ 
ment  (as  depicted  in  Figure  4),  ensures  that  no  informa¬ 
tion  is  revealed  unless  all  members  Mt  reveal  their  “match” 
nonce’s  hash  HNnij  because  the  devices  would  not  reveal 
the  decryption  key  Nnij.  Hence,  if  any  group  member  de¬ 
tects  an  anomaly  before  the  hash  comparison,  all  devices 
will  abort  the  protocol.  The  multi-commitment  also  pre¬ 
vents  the  collision  attack  on  the  low-entropy  hash  that  is 
used  for  the  comparison,  by  computing  the  hash  over  the 
ordered  triplets  ( // N:, .  G* ,  E, ) .  Since  the  commitment  C,  = 
H(HNj  ||  Gj  ||  Ej)  locks  in  the  value  of  the  triplet,  an  ad¬ 
versary  cannot  change  its  triplet  or  predict  any  other  triplet 
before  the  hash  is  pre-determined  through  all  users’  choices. 
Hence,  the  attacker  only  has  a  chance  of  1  in  224  to  create  a 
collision,  which  is  sufficiently  small  for  our  purpose. 

5.5  Discussion 

In  this  section,  we  discuss  the  rationale  behind  design  de¬ 
cisions  we  made. 

With  respect  to  the  server’s  grouping  approach,  we  con¬ 
sidered  numerous  alternatives.  The  BUMP  application  [5] 
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performs  the  grouping  by  having  two  users  “bump”  their 
phones  together,  and  by  measuring  location,  time,  and  accel¬ 
eration  the  server  can  pair  up  the  two  phones.  Although  this 
approach  is  fun  for  the  users,  we  did  not  use  if  for  numerous 
reasons:  (1)  BUMP  reveals  the  user  location  to  the  server, 
which  is  an  invasion  of  privacy,  (2)  the  approach  is  not  se¬ 
cure  as  a  malicious  bystander  can  simultaneously  simulate 
the  bump  and  often  be  paired  with  one  of  the  two  devices  and 
steal  the  user’s  contact  information  [38],  (3)  does  not  scale 
to  more  than  2  users,  (4)  cannot  be  performed  remotely  over 
the  telephone,  (5)  acquiring  the  location  can  be  unreliable 
and  often  has  a  delay  of  10  seconds  or  more,  (6)  the  protocol 
is  often  unreliable  and  the  server  cannot  pair  the  devices. 

Another  alternative  for  grouping  we  considered  is  to  use 
ambient  noise,  but  this  may  also  reveal  privacy-sensitive  sound 
to  the  server,  and  may  also  be  unreliable  in  many  circum¬ 
stances.  We  finally  settled  on  the  unique  ID  assignment  by 
the  server  and  having  users  find  and  enter  the  lowest  ID, 
which  is  fast  and  reliable,  and  can  be  fun  as  users  compete 
to  see  who  is  “the  winner”.  Based  on  the  IDs,  all  the  server 
needs  is  to  end  up  with  a  connected  graph,  where  each  de¬ 
vice  represents  a  node  and  an  edge  is  formed  by  having  one 
device  send  the  ID  of  another  device  to  the  server.  We  con¬ 
sidered  the  approach  of  having  users  simply  enter  an  ID  of 
any  other  user,  but  this  may  be  confusing  in  case  multiple 
users  are  present,  it  can  also  lead  to  a  non-connected  graph 
in  case  there  are  more  than  3  users.  By  having  users  enter  the 
lowest  ID,  the  resulting  graph  forms  a  star  topology,  which 
is  connected. 

A  point  of  frequent  confusion  is  that  people  believe  that 
the  members  who  perform  the  exchange  are  the  only  group 
that  can  communicate.  This  is  not  the  case,  however.  The 
SafeSlinger  exchange  protocol  is  only  used  for  acquiring 
other  users’  information  in  a  secure  fashion.  Since  the  con¬ 
tact  information  includes  a  public  key,  only  that  public  key  is 
used  to  establish  subsequent  secure  communication.  In  par¬ 
ticular,  all  cryptographic  values  created  during  the  exchange 
(as  phraseed  in  Figure  3  are  erased  right  after  the  exchange  - 
the  sole  purpose  of  their  brief  existence  was  to  protect  a  sin¬ 
gle  exchange.  Subsequent  secure  group  communication  can 
be  easily  established  by  using  the  exchanged  public  keys  in 
conjunction  with  a  group  DH  protocol,  in  which  case  it  does 
not  matter  whether  the  public  keys  of  other  group  members 
were  acquired  in  the  same  or  in  several  separate  exchange 
sessions.  Thus,  there  is  no  relationship  of  the  group  that  was 
used  to  exchange  the  information  and  subsequent  member¬ 
ship  composition  of  secure  group  communication. 

6.  IMPLEMENTATION 

The  implementation  of  SafeSlinger  runs  on  a  central  server 
and  multiple  smartphone  platforms.  The  client  application 
is  written  for  Android  2.1  in  Java  and  Apple  iOS  3.0  in 
Objective-C.  The  server  application  is  written  for  the  Google 
App  Engine  platform  in  Python.  We  tested  our  key  exchange 
over  cellular  and  Wi-Fi  networks  and  on  several  smartphone 
devices:  Motorola  Droid  855,  Google  Nexus  S,  Samsung 


Galaxy,  Samsung  Galaxy  SII,  Apple  iPod  Touch,  and  Apple 
iPhone  4. 

In  this  section  we  provide  an  overview  of  design  decisions 
intended  to  optimize  the  adoptability  and  usability  of  our  key 
exchange  and  a  detailed  walk-through  of  the  steps  in  a  key 
exchange  protocol  execution.  Usability  aspects  drove  many 
of  our  design  considerations  to  make  the  experience  conve¬ 
nient,  efficient,  and  comfortable  to  use. 

Figure  5  depicts  the  steps  for  a  contact  list  exchange.  In 
5(a)  we  can  see  how  a  user  can  select  the  entries  of  the  con¬ 
tact  list  to  share.  5(b)  shows  the  dialog  where  the  number 
of  users  are  selected,  the  next  entry  on  the  bottom  that  is  not 
visible  selects  “8  or  more  users”,  which  would  trigger  the 
Ho-Po  Key  protocol.  In  5(c),  the  user  sees  her  unique  ID 
assigned  by  the  server  and  enters  the  lowest  ID  of  any  user 
in  the  group.  The  word  phrase  selection  screen  is  shown  in 
5(d),  and  if  all  operations  were  successful,  in  5(e)  the  user 
can  select  which  contact  list  entries  to  import  into  which  of 
their  address  book  accounts. 

6.1  Address  Book  Key  Management 

As  our  implementation  attempts  to  share  contact  data  and 
keys  with  others,  we  rely  heavily  on  use  of  the  mobile  op¬ 
erating  systems’  contact  list.  At  the  beginning  of  our  ex¬ 
change,  each  user  must  identify  which  contact  entry  they 
wish  to  use  as  their  identity,  or  create  one.  Since  we  want 
to  provide  a  place  to  store  public  key  data  for  the  user,  it 
would  be  beneficial  to  keep  it  in  a  recognizable  field  that  the 
smartphone’s  address  book  synchronization  service  would 
backup  for  us  offline.  We  extend  the  ability  for  the  contact 
list  to  store  the  name  and  value  of  a  new  instant  messaging 
(IM)  provider.  Some  contact  synchronization  services  may 
require  ASCII-only  values  in  this  IM  field,  so  we  Base-64 
encode  our  public  key  under  a  custom  label  that  the  third- 
party  application  defines.  Further  discussion  of  this  API  can 
be  found  in  Section  7.1. 

6.2  vCard  Construction 

Before  we  can  send  our  contact  information  we  need  to 
format  it  in  a  standard  manner  so  that  will  be  recognizable 
across  platforms.  We  format  our  contact  data  in  vCard  3.0,3 
and  the  key  material  specifically  uses  the  IETF  vCard  Ex¬ 
tensions  for  Instant  Messaging4  proposal.  We  use  this  IMPP 
field  type  with  a  naming  pattern  so  that  keys  are  arbitrary 
data  to  the  key  exchange  which  do  not  require  special  han¬ 
dling  relative  to  other  contact  fields.  This  will  encourage 
developers  to  adopt  the  exchange  of  key  material  or  other 
data  made  available  by  SafeSlinger  without  creating  special 
support  for  their  application.  The  SafeSlinger  Messaging  ap¬ 
plication  (Section  7.2)  uses  the  labels  “SafeSlinger-PubKey” 
and  “SafeSlinger-Push”  for  its  public  key  and  push  token 
which  can  be  seen  in  Figure  5(a).  Although  we  have  mod¬ 
ified  the  vCard  construction  to  share  these  public  keys  in 

3http://  tools.ietf.org/html/rfc2426 

4http  ://tools .  ie  tf .  org/html/rfc47 7 0 
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SafeSlinger  -  Begin  Exchange 


Alice 


Check  items  you  wish  to  share 
and  tap  'Begin  Exchange’  when 
others  are  ready  to  exchange. 
\*s\  roi  photo 

[✓]  (*  Mobile  026-668-1864 

Home  alice@wonderland.net 
fl  custom  SafeSlinger-Push 

6  custom  SafeSlinger-PubKey 

\J\  Home  1  Follv  Bridae,  Oxford.  0 

Begin  Exchange 
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SafeSlinger  -  Grouping 


This  number  is  used  to  create  a 
unique  group  of  users.  Compare, 
then  enter  the  lowest  number 
among  all  users. 


Lowest 


OK 


1  2  ABC  3  DEF 

4  GHI  5  JKL  6  MNO 

7  PQRS  8  TUV  9  WXYZ  €3 

*#  0+  4-^ 


All  phones  must  match  one  of  the 
3-word  phases.  Compare,  then 
pick  the  matching  phrase. 


O  buzzard  tambourine  concert 
Otransit  nebula  egghead 
O  exceed  Norwegian  breakup 


*  .3, 

•=?.,!  ■  5:08 

SafeSlinger  -  End  Exchange 

© 

Exchange  Complete!  Select 
member  data  to  save  to  your 
Address  Book: 


[✓]  Mad  Hatter 
[✓]  White  Rabbit 


Save  Account 

hopokey@gmail.com 


Import 


&■ 

4 


(a)  Data  selection 


(b)  Number  of  users 


(c)  Lowest  ID 


(d)  Word  phrase  compar¬ 
ison 


(e)  Contact  import 


Figure  5:  Secure  contact  information  exchange  sequence. 


the  IMPP  field  which  translate  to  fields  that  can  be  synchro¬ 
nized,  no  smartphone  OS  currently  supports  the  import  or 
export  of  the  existing  KEY  field  supported  in  vCard  3.0. 

6.3  Contact  Data  Confidentiality 

The  contact  data  we  share  in  the  exchange  is  encrypted 
using  AES  in  CBC  mode  with  PKCS7  padding.  The  actual 
encryption  key  Kq  and  initialization  vector  IVd  are  derived 
from  the  160-bit  “match”  nonce  Am,-: 

Kd  =  [HMAC-SHA-ljvm;(l)]i28, 

IVd  =  [HMAC-SHA-ljvm(.(2)]i28-  The  [x]y  notation  indicates 
that  the  value  x  is  truncated  to  the  y  least  significant  bits. 
Contact  data  integrity  is  achieved  through  verification  of  the 
commitment  Q,  hence,  no  additional  Message  Authentica¬ 
tion  Code  (MAC)  is  needed. 

As  we  discuss  in  Section  5,  the  “match”  nonce  needs  to 
be  distributed  encrypted  by  K  (the  private  key  of  the  root 
node  of  the  group  DH  key  tree).  The  encryption  is  using 
AES  in  CBC  mode  with  PKCS7  padding,  where  the  AES 
key  derived  from  the  group  DH  key  K  as  follows:  Kqbc  ~ 
[HMAC-SHA- 1  1  )1 128-  Since  we  can  validate  Am,  based 

on  the  committed  value  Hint,  no  additional  MAC  value  is 
needed  to  ensure  integrity  and  authenticity  for  that  encryp¬ 
tion. 

6.4  Fast,  Consistent,  Wireless  Communication 

We  chose  an  Internet-based  communication  protocol  over 
several  other  approaches.  Bluetooth  provides  proximity  and 
avoids  use  of  a  server,  but  can  be  slow  to  discover  devices, 
may  require  barcode  scans  to  improve  discovery,  and  may  be 
difficult  for  all  devices  to  play  equal  roles  in  the  exchange  if 
one  device  acts  as  a  host  to  the  others.  In  addition,  Blue¬ 
tooth  pairing  may  be  restricted  to  certain  devices  depending 
on  how  the  smartphone  OS  implementation.  Ad-hoc  Wi¬ 
Fi  broadcast  messages  may  allow  each  device  to  play  an 
equal  role,  but  suffer  from  lack  of  widespread  availability  on 
the  most  popular  smartphone  platforms.  While  proximity- 
based  communication  protocols  may  assist  in  the  grouping 


process,  they  still  cannot  defend  against  an  adversary  with 
a  strong  amplifier  and  a  high-gain  antenna  who  could  still 
participate  in  the  protocol  from  a  distance.  Internet-level 
messages  (Wi-Fi,  GSM,  EVDO)  between  smartphones  and 
server  provide  an  equal  role  for  each  device,  and  provides 
fast  message  exchange.  Moreover,  Internet-based  communi¬ 
cation  enables  remote  operation  of  the  information  exchange, 
assuming  the  users  can  communicate  over  a  channel  that  en¬ 
ables  them  to  authenticate  each  other,  such  as  voice  over 
telephone  or  video  conferencing  (pure  text  over  SMS  or  MMS 
could  be  easily  spoofed  in  a  MitM  attack). 

6.5  Server  Data  Management 

Our  server,  written  in  Python  for  Google  App  Engine, 
consists  of  a  simple  database  table  to  hold  the  message  data 
submitted  by  each  member  of  the  group  at  any  given  time. 
The  lifetime  of  this  data  is  10  minutes,  since  we  have  im¬ 
plemented  a  script  which  removes  all  entries  older  than  that 
window  of  time. 

In  return  for  a  device  submitting  the  initial  commitment 
C,,  the  server  assigns  a  simple  grouping  ID  //),,  and  returns 
it  to  the  user.  This  grouping  ID  is  chosen  by  the  server  such 
that  it  will  be: 

•  Pseudo-random,  to  reduced  predictability. 

•  Low-entropy,  to  reduce  user  error  and  effort  for  choos¬ 
ing  and  entering  the  lowest  number  (Figure  5(c)). 

These  properties  are  achieved  by  querying  the  table  for 
remaining  sets  of  available  grouping  IDs  first  in  the  exclusive 
range  1-9,  removing  collisions  with  numbers  currently  in 
use,  and  using  a  random  function  to  pick  and  assign  from 
what  remains.  Should  all  9  numbers  in  the  lowest  set  be  in 
use,  the  query  is  repeated  for  the  range  10-99.  Similarly,  if 
those  numbers  are  in  use,  we  continue  to  increase  the  range 
to  100-999  and  so  on. 

6.6  Server  Supported  Messages 

Our  SafeSlinger  information  exchange  protocol  depends 
fundamentally  on  the  ability  for  each  client  to  validate  all 
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data  received  from  other  members  without  trusting  the  server 
or  the  network  communication.  Nevertheless,  to  reduce  the 
effect  of  potential  network-based  attacks,  we  set  up  an  SSL 
connection  between  the  client  and  server. 

The  communication  happens  through  a  pull  model,  where 
the  client  sends  HTTPS  POST  calls  to  the  server  to  request 
transmission  of  as  much  information  possible  at  each  step. 

Each  client  will  accept  information  from  up  to  N  —  1  other 
users,  where  N  is  the  number  of  group  members  the  user 
selected.  The  server  stores  each  piece  of  client  information 
for  up  to  10  minutes  before  an  automatic  cleanup  routine 
removes  it  from  the  server  database. 

Our  server  supports  the  following  messages: 

1 .  Mj  sends  commitment  Q,  server  responds  with  group¬ 
ing  ID  ZD,. 

2.  M/  sends  IDX  of  each  Cx  it  has,  server  responds  with 
any  Cx  client  does  not  yet  have. 

3.  Mj  sends  IDX  of  each  (H Nx.  Gx.  Ex)  triplet  it  has,  server 
responds  with  any  (HNy,Gy,Ey)  triplet  the  client  lacks. 

4.  Mj  sends  IDX  of  each  ( Hm'x,Hwx )  tuple  it  has,  server 
responds  with  any  ( Hm',Hwy )  tuple  the  client  still  needs. 

5.  In  groups  with  more  than  2  users,  send  the  public  group 
DH  tree  value  V,  of  an  intermediate  node  of  the  group 
DH  tree.  (Section  3.2  describes  the  group  DH  tree.) 

6.  In  groups  with  more  than  2  users,  request  the  public 
group  DH  tree  value  V)  of  an  intermediate  node  of  the 
group  DH  tree. 

7.  Mj  sends  IDX  of  each  {Nmx\ k  it  has,  server  responds 
with  any  {Nmy}f(  the  client  still  needs. 

6.7  Word  Phrase  Verification 

Each  user  must  compare  their  separate  calculations  of  the 
hash  of  all  data  exchanged  in  the  protocol  as  a  PGP  word 
phrase  based  3-word  phrase  and  we  aim  to  discourage  any 
careless  comparison  of  this  hash. 

We  use  the  standard  PGP  approach  for  converting  a  24- 
bit  hash  value  into  3  words.  PGP  uses  two  word  lists,  an 
“even”  and  “odd”  list  with  256  words  each.  In  SafeSlinger, 
the  word  phrase  is  constructed  from  the  first  24  bits  of  the 
160  bit  SHA-1  hash,  as  indicated  in  Step  11  of  Figure  3. 
Based  on  the  standard  PGP  approach,  the  first  8  bits  select  a 
word  in  the  “even”  list,  the  second  8  bits  select  a  word  in  the 
“odd”  list,  and  the  final  8  bits  select  another  word  from  the 
“even”  list. 

In  addition  to  the  common  phrase  displayed  on  each  de¬ 
vice,  we  construct  2  more  decoy  phrases  for  each  device. 

In  this  way,  users  are  forced  to  compare  phrases  with  at 
least  one  other  user  and  choose  which  phrase  matches  among 
them.  However,  to  prevent  attacks,  all  users  need  to  validate 
that  they  all  have  the  same  word  phrase.  The  word  phrase 
provided  in  this  exchange  will  enable  out-of-band  verifica¬ 
tion  in  proximity  where  users  may  view  each  other’s  screen, 
or  over  the  phone  /  teleconference,  where  the  users  read  their 
word  phrase  out  loud.  In  some  contexts,  it  may  be  consid¬ 
ered  impolite  in  common  company  to  look  at  or  take  a  pic¬ 
ture  of  another  user’s  phone,  and  thus  this  protocol  provides 


screen  privacy  and  sharing  of  phrases  in  comfortable  con¬ 
versation.  The  audio  sharing  of  the  verification  phrase  also 
allows  users  to  perform  the  exchange  remotely  while  speak¬ 
ing  on  the  telephone,  since  they  will  recognize  each  other’s 
voices  and  can  be  assured  of  the  others  physical  presence  in 
real-time  remotely. 

6.8  Word  Phrase  Collision  Avoidance 

If  a  word  in  our  decoy  word  phrases  is  the  same  as  in 
the  actual  word  phrase,  users  may  get  confused  and  select 
the  decoy  word  phrase  as  the  match.  Although  unlikely,  the 
words  in  a  decoy  phrase  may  match  the  words  in  a  decoy 
phrase  on  another  device,  causing  the  user  to  select  the  decoy 
phrase  which  results  in  an  error  detected  by  the  local  device. 

We  want  to  avoid  true  randomness  in  the  decoy  phrases 
so  that  careless  users  will  not  chose  the  wrong  phrase  if  the 
actual  hash  phrase  and  either  of  the  decoy  phrases  contain 
the  same  word  in  the  same  position. 

We  thus  chose  our  decoy  phrases  deterministically  such 
that  each  decoy  word  will  be  unique  across  all  decoy  phrases 
displayed  in  the  group.  After  computing  the  actual  word 
phrase,  we  mark  all  words  as  used.  Using  the  original  160- 
bit  verification  hash,  we  repeatedly  hash  it  with  SHA-1,  us¬ 
ing  the  bits  produced  as  follows.  We  assign  all  decoy  words 
to  each  decoy  word  list  by  user  id  IDX  in  descending  order, 
producing  24  bits  for  IDa  decoy  phrase  1,  then  lDa  decoy 
phrase  2,  then  ZD/,  decoy  phrase  1,  then  ZD/,  decoy  phrase  2, 
until  each  client  has  produced  their  own  2  decoy  phrases  and 
can  display  them  with  the  actual  hash  phrase.  During  the 
selection  process,  if  a  selected  words  is  already  marked  as 
consumed,  it  will  be  skipped  and  the  next  available  word  in 
the  list  will  be  used.  Newly  selected  words  are  also  marked 
as  consumed.  Duplicate  words  (i.e.,  the  first  and  third  words 
may  be  the  same  since  they  are  picked  from  the  same  “even” 
list)  within  the  same  phrase  are  permitted. 

This  method  assures  that  all  decoy  phrases  contain  words 
that  will  not  collide  with  each  other  or  the  actual  word  phrase 
for  all  users  N.  Since  we  use  the  words  from  the  “even”  list 
twice  as  fast  as  the  “odd”  list,  we  can  at  most  support  63 
users,  as  ((4*64) +2)  >256. 

7.  APPLICATIONS 

We  have  fully  implemented  the  SafeSlinger  Key  Exchange 
as  an  API  library  in  Android  2.1  and  as  a  utility  applica¬ 
tion  in  Apple  iOS  3.0.  Any  third-party  application  for  either 
platform  may  compile  into  or  execute  the  key  exchange  in¬ 
cluding  its  GUI.  Additionally,  we  have  leveraged  our  key  ex¬ 
change  to  create  a  text  messaging  and  a  file  exchange  appli¬ 
cation  for  Android  2.1.  We  will  discuss  the  potential  of  these 
applications  here,  and  describe  an  application  for  providing 
secure  introduction.  The  Android  beta  version  of  our  key 
exchange  and  messaging  implementation  can  be  found  on 
the  Android  Market.  The  iOS  version  of  our  key  exchange 
will  be  available  from  the  iTunes  App  Store  soon  (it  is  cur¬ 
rently  available  as  KeySlinger,  but  we  will  soon  update  it  to 
SafeSlinger),  and  the  full  SafeSlinger  iOS  application  with 
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full  encrypted  messaging  and  file  exchange  support  will  be 
available  in  early  2012. 

7.1  Secure  Key  Exchange  API 

The  purpose  of  the  secure  key  exchange  API  is  to  enable 
third-party  applications  to  leverage  SafeSlinger  to  exchange 
public  keys  with  other  users  in  an  authenticated  fashion.  For 
example,  a  secure  email  application  can  export  its  public  key 
to  SafeSlinger  and  use  it  as  a  transport  to  safely  sling  the 
key  to  other  users.  On  the  other  user’s  platform,  the  secure 
email  application  will  pull  out  the  public  key  and  use  it  to 
authenticate  received  or  encrypt  to-be-sent  email. 

Our  secure  key  exchange  API  may  be  launched  from  a 
third-party  application.  Cryptographic  operations  are  com¬ 
puted  using  the  operating  system-provided  libraries  for  An¬ 
droid  and  iOS,  with  the  addition  of  open  source  OpenSSL5 
libraries  for  Apple  iOS.  Figure  6  shows  the  information  flow 
between  multiple  devices  during  execution  of  the  key  ex¬ 
change,  outlined  as  follows. 

1 .  Third-party  application  generates  a  public/private  key 
pair. 

2.  Third-party  application  inserts  its  public  key  in  the  de¬ 
vice’s  contact  list. 

3.  Third-party  executes  the  SafeSlinger  key  exchange  API 
providing  the  location  of  its  contact  in  the  contact  list 
and  name  of  the  public  key  to  exchange  as  parameters. 

4.  During  the  SafeSlinger  key  exchange  protocol  (Sec¬ 
tion  5),  multiple  messages  are  exchanged  between  de¬ 
vices  via  our  server,  and  validated  independently  by 
each  device. 

5.  SafeSlinger  key  exchange  saves  the  new  public  key  and 
contact  data  received  in  the  device’s  contact  list. 

6.  Third-party  applications  may  now  make  use  of  newly 
imported  public  keys  from  the  contact  list. 

7.2  Messaging  Implementation 

We  have  implemented  SafeSlinger  text  messaging  and  file 
exchange  for  the  Android  2. 1  OS  and  leverage  the  secure  in¬ 
formation  exchange  to  share  public  keys  that  are  used  in  turn 
to  encrypt  text  messages  and  file  data.  When  SafeSlinger 
first  starts,  it  generates  a  RSA  2048-bit  key  pair.  The  appli¬ 
cation  then  obtains  a  Google  Android  C2DM  Push  token6 
for  addressing  the  device.  During  a  SafeSlinger  informa¬ 
tion  exchange,  the  public  keys  and  push  tokens  of  all  group 
members  are  exchanged  and  imported  into  the  address  book. 

The  actual  messages  and  files  that  are  sent  are  encrypted 
and  authenticated  in  the  OpenPGP7  message  format,  to  pro¬ 
vide  compatibility  with  other  PGP  applications.  The  An¬ 
droid  implementation  uses  the  open-source  Bouncy  Castle8 

5  http://www.openssl.org 

6C2DM  Push  was  first  released  for  Android  2.2  OS.  Unfortunately, 
Android  2. 1  devices  can  only  send  but  not  receive  messages,  how¬ 
ever,  they  represent  about  10%  of  current  Android  devices. 

7http://tools. ietf.org/html/rfc4880 

8http://www.bouncycas  tle.org 
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Figure  6:  SafeSlinger  secure  key  exchange  API  interac¬ 
tion. 


library  in  Java  for  formatting  OpenPGP  messages.  Our  iOS 
implementation  uses  the  the  open  source  OpenPGP:SDK9 
library  in  C  for  formatting  OpenPGP  messages. 

The  sender  constructs  an  encrypted  text  message  using  an 
OpenPGP  message  format  by  encrypting  the  plaintext  text 
message  with  the  recipient’s  public  key,  and  signed  using  the 
sender’s  private  key.  The  sender  uses  the  recipient’s  push  to¬ 
ken  as  an  address  to  send  the  encrypted  text  message  to.  The 
recipient  will  decrypt  the  OpenPGP  message  using  the  recip¬ 
ient’s  private  key  and  verify  the  OpenPGP  signature  using 
the  sender’s  public  key. 

While  OpenPGP  supports  many  message  formats,  we  chose 
a  limited  set  of  options  to  ensure  cross-platform  compatibil¬ 
ity  in  this  early  implementation.  We  used  AES-256  for  our 
symmetric  encryption  algorithm  and  SHA-1  for  our  signa¬ 
ture  hash  algorithm.  Since  OpenPGP  is  a  well-defined  and 
widely  used  messaging  standard,  we  did  not  attempt  to  re¬ 
peat  the  efforts  of  those  who  have  tested  its  properties  in  the 
past.  Our  aim  is  to  implement  a  system  that  makes  use  of  our 
key  exchange  API  so  that  others  may  evaluate  its  benefits  for 
inclusion  in  their  own  systems. 

Sample  screenshots  from  our  messaging  application  are 
depicted  in  Figure  7.  In  ??  we  can  see  the  login  screen  re¬ 
quiring  a  password  entry.  7(a)  shows  the  message  composi¬ 
tion  and  the  current  selected  image  that  is  ready  to  be  sent. 
Finally,  7(c)  shows  the  received  message  screen  along  with  a 
decrypted  message  that  indicates  a  received  file  that  is  ready 
to  be  downloaded  and  viewed. 

7.2.1  Push  Message  Notification 

We  make  use  of  push  notifications  on  smartphone  operat- 

9http://openpgp.  nominet.org.  uk 
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(a)  Message  composition  (b)  Message  list  with  en-  (c)  Message  list  with  de¬ 
crypted  message  crypted  message 


Figure  7:  Secure  Messaging  Screenshots. 


ing  systems  to  deliver  message  data,  to  avoid  text  messaging 
charges  for  our  users,  and  to  conserve  battery  energy.  Push 
notifications  are  a  better  solution  to  any  low-power  device 
which  must  make  constant  contact  to  a  server  for  data  up¬ 
dates.  Rather  than  requiring  each  application  developer  to 
implement  a  background  task  to  keep  a  separate  connection 
to  their  server  to  poll  for  updates,  push  notifications  are  an 
OS-provided  unified  update  service  in  which  the  OS  main¬ 
tains  one  connection  to  its  own  notification  service.  Then, 
each  developer  can  register  their  application  with  the  OS 
push  service,  and  the  OS  only  needs  to  maintain  one  connec¬ 
tion  to  check  for  updates  across  several  applications  which 
the  user  may  have  installed,  preserving  battery  energy. 

Our  Android  implementation  uses  the  Android  Cloud  to 
Device  Messaging10  framework  (C2DM)  for  push  notifica¬ 
tions,  and  our  iOS  implementation  uses  the  Apple  Push  No¬ 
tification  Service  (APNS).* 11  Since  APNS  is  not  available  to 
use  directly  from  Google  App  Engine,  we  use  an  intermedi¬ 
ary  service.  Urban  Airship  (UA)12  to  bridge  this  gap. 

7.2.2  Messaging  Server  Construction 

We  must  work  within  the  size  limitations  of  these  push 
messages.  C2DM  push  messages  cannot  exceed  1024  bytes, 
while  APNS  messages  may  not  exceed  256  bytes.  This  may 
not  allow  a  OpenPGP  formatted  text  message  to  fit,  so  we 
create  a  160  bit  random  nonce  to  act  as  a  message  UUID  or 
retrieval  token  for  each  message  the  user  sends. 

When  a  user  wants  to  send  a  message,  we  pass  to  our 
server:  a  message  retrieval  token;  the  push  token  and  no¬ 
tification  type  (C2DM  or  UA/APNS)  of  the  recipient;  an 
OpenPGP  message  containing  text;  identity,  and  file  preview 
data;  and  optionally  another  OpenPGP  message  (up  to  10 
MB)  containing  the  file  itself.  The  two  OpenPGP  messages 
are  stored  in  the  server  datastore  for  24  hours  before  auto¬ 


matic  deletion,  and  we  construct  and  send  a  push  message 
to  the  notification  service  type  specified  containing  just  the 
message  retrieval  token.  When  the  recipient’s  OS  push  ser¬ 
vice  collects  the  push  message,  it  will  launch  SafeSlinger  to 
read  the  message,  and  then  SafeSlinger  will  notify  the  user 
that  a  message  is  available  for  download. 

7.2.3  Secure  Text  Messages 

The  text  message  itself,  along  with  user  name  or  verifi¬ 
cation,  timestamp,  and  preview  data  of  any  attachments  are 
formatted  as  an  OpenPGP  message.  After  the  recipient  re¬ 
ceives  the  push  message,  they  can  download  the  text  mes¬ 
sage,  decrypt  and  verify  it. 

7.2.4  Secure  File  Transfer 

Similar  to  our  Secure  Messaging  application,  we  have  im¬ 
plemented  SafeSlinger  file  transfer  for  the  Android  2.1  OS 
and  leverage  the  key  exchange  to  share  public  keys  and  en¬ 
crypt  files  stored  on  our  smartphones  such  as  images  and 
music,  or  other  large  binary  data.  Our  implementation  al¬ 
lows  any  file  just  under  2GB  in  size  to  be  transmitted  as  an 
OpenPGP  message.  The  file  formatted  as  a  separate  OpenPGP 
message  described  prior,  and  downloaded  with  the  same  re¬ 
trieval  token  as  the  text  message  token. 

We  make  use  of  the  Intents  in  Android  OS  to  advertise 
to  other  applications  that  SafeSlinger  Messaging  is  available 
for  sending  media  files  to  other  people.  In  this  way,  users 
viewing  a  photo  in  their  photo  gallery  application  can  se¬ 
lect  “share”  from  the  menu  and  receive  a  list  of  applications 
which  includes  SafeSlinger  to  transmit  the  photo  to  another 
user.  We  have  enabled  images,  video,  audio,  vCards,  text, 
and  other  application  files  to  use  SafeSlinger  for  transmis¬ 
sion  to  other  users. 

7.3  Secure  Introduction 


10http://code. google.com/android/c2dm 

1 1  http  ://support .  apple .  com/kb/HT 3576 
12http://urbanairship.com/docs 
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Based  on  the  secure  file  transfer  mechanism  we  have  im¬ 
plemented,  we  can  support  secure  introductions,  where  a 
common  friend  of  two  users  sends  contact  data  that  includes 


public  keys  to  each  other.  More  concretely,  consider  Alice 
with  two  friends:  Bob  and  Carol.  Alice  has  performed  a 
SafeSlinger  exchange  with  both  Bob  and  Carol  and  has  thus 
received  an  authentic  SafeSlinger  public  keys  for  both  Bob 
and  Carol,  vice-versa,  both  Bob  and  Carol  have  Alice’s  au¬ 
thentic  SafeSlinger  public  key.  In  a  secure  introduction,  Al¬ 
ice  first  encodes  Bob’s  contact  information  (which  includes 
Bob’s  SafeSlinger  public  key  and  Push  token)  as  a  custom 
vCard  and  uses  an  OpenPGP  message  format  to  protect  se¬ 
crecy  and  authenticity.  Alice  then  sends  this  message  via  a 
SafeSlinger  transfer  to  Bob.  Hence,  Bob  can  validate  that  the 
information  indeed  originates  from  Alice,  whom  he  trusts 
not  to  send  bogus  information.  Analogously,  Carols  trusts 
Bob’s  information  received  from  Alice.  Now  that  Bob  and 
Carol  have  each  other’s  public  keys  and  push  tokens,  they 
can  use  SafeSlinger  to  securely  communicate. 

8.  EVALUATION 

We  evaluated  SafeSlinger  on  2  to  5  devices.  Our  pop¬ 
ulation  includes  2  Motorola  Droid  devices  under  Android 
2.2.3  OS  and  3  Google  Nexus  S  devices  under  Android  2.3.6 
OS.  Our  devices  were  using  a  mixture  of  cellular  messages 
through  3G,  and  Wi-Fi  messages  through  Carnegie  Mellon’s 
campus  wireless  access  points. 

Our  measurements  include  5  phases  of  the  SafeSlinger 
protocol  between  the  sending  the  user’s  initial  commitment 
(S4)  and  receiving  the  final  decryption  key  (S17)  as  detailed 
in  Figure  3.  We  include  3  phases  in  which  client  and  server 
communicate:  ID  Assignment,  Data  Verification,  and  Match 
Verification ,  and  2  phases  where  users  must  select  matching 
values:  Low  ID  Selection  and  Phrase  Selection  (Figure  8). 

•  ID  Assignment  includes  communication  time  to  sub¬ 
mit  the  user’s  initial  commitment  and  for  the  server  to 
assign  and  return  an  unique  grouping  ID  (S4-S5). 

•  Low  ID  Selection  includes  the  user’s  time  to  compare 
and  enter  the  lowest  grouping  ID  (S5-S8). 

•  Data  Verification  includes  communication  time  between 
client  and  server  to  collect  all  other  user’s  initial  com¬ 
mitments  under  the  chosen  grouping  ID,  and  to  dis¬ 
tribute  and  verify  the  decommitments  (S8-S10). 

•  Phrase  Selection  includes  the  user’s  time  to  compare 
and  select  the  3 -word  phrase  that  matches  with  other 
user’s  (S10-S 14). 

•  Match  Verification  includes  communication  time  be¬ 
tween  client  and  server  to  distribute  and  verify  all  “match” 
or  “no  match”  multi-value  commitments,  calculate  the 
shared  secret  key,  distribute  intermediate  group  DH 
tree  nodes  (in  case  of  groups  with  more  than  2  users), 
and  to  and  to  distribute  and  verify  the  encrypted  match 
nonce  (S14-S17). 

Except  for  the  calculation  of  the  shared  secret  key,  these 
measurements  do  not  include  the  time  to  generate  nonces  or 
symmetric  keys,  or  to  encrypt  or  decrypt  the  user’s  vCard 
data,  which  is  negligible  compared  to  the  other  overheads. 


Figure  8:  Time  consumed  during  a  SafeSlinger  ex¬ 
change. 

Our  results  (Table  1)  indicate  that  the  total  run  time  for  2 
users  is  a  comfortable  average  of  17  seconds  to  complete  the 
exchange.  The  total  time  is  close  to  35  and  40  seconds  for  4 
and  5  devices,  respectively. 

The  increased  time  for  larger  numbers  of  participants  is 
mainly  due  to  the  additional  bandwidth  required  for  the  ad¬ 
ditional  information,  as  well  as  the  additional  processing,  es¬ 
pecially  for  the  STR  group  Diffie-Hellman  protocol  requir¬ 
ing  expensive  modular  exponentiations.  As  we  can  see  from 
the  table,  the  execution  time  is  efficient  and  usable. 

9.  RELATED  WORK 

Closely  related  research  by  Asokan-Ginzboorg  [2],  Ab- 
dalla  et  al.  [1],  Valkonen  et  al.  [39],  and  Laur  and  Pasini  [20] 
provide  techniques  for  secure  local  establishment  of  a  shared 
secret  key  without  relying  on  PKIs  or  any  prior  trusted  infor¬ 
mation.  Unfortunately,  a  secret  shared  among  nodes  cannot 
be  used  to  provide  integrity  and  authenticity  for  exchanged 
messages,  because  any  malicious  group  member  with  the 
key  could  have  created  that  message.  Therefore,  a  shared 
secret  is  insufficient  for  secure  exchange  of  authentic  infor¬ 
mation.  In  particular,  GitM  attacks  are  possible,  exploiting 
the  absence  of  message  authenticity. 

The  most  closely  related  works  provide  secure  group-based 
exchange  of  contact  information:  GAnGS  [8],  SPATE  [22, 
23],  Ho-Po  Key  [30],  and  Nithyanand  et  al.  [32], 

The  GAnGS  protocol  [8]  was  designed  to  scale  trust  es¬ 
tablishment  to  a  larger  number  of  users  -  it  supports  large 
groups  of  25  or  more  users.  Unfortunately,  GAnGS  requires 
users  to  perform  many  operations  and  is  thus  cumbersome 
to  use.  SPATE  [22, 23]  was  designed  for  contact  exchange 
in  smaller  groups  (8  or  fewer  people).  SafeSlinger  offers  nu¬ 
merous  improvements  over  these  prior  systems:  (1)  GAnGS 
and  SPATE  required  the  acquisition  of  a  2D  barcode  dis¬ 
played  by  another  phone,  which  can  require  a  significant 
amount  of  time  especially  in  difficult  lighting  conditions  such 
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Table  1:  Average  execution  time  per  number  of  devices  (unit:  second ),  averaged  over  5  runs  with  standard  deviation  in 
parenthesis 


#  of  Devices 

ID  Assignment 

Low  ID  Selection 

Data  Verification 

Phrase  Selection 

Match  Verification 

Total 

2 

0.31  (0.24) 

3.20  (0.99) 

3.77  (0.18) 

6.64(1.66) 

2.66  (0.23) 

16.58  (2.39) 

3 

1.00  (0.61) 

3.53  (1.17) 

5.78  (1.07) 

6.36(1.66) 

5.95  (1.69) 

22.62  (3.84) 

4 

3.27(1.62) 

2.76  (0.90) 

7.81  (1.05) 

7.37  (3.73) 

12.41  (2.89) 

33.62  (6.01) 

5 

3.82  (0.64) 

4.55  (1.06) 

9.27  (0.82) 

3.87  (0.38) 

16.29(1.61) 

37.84(1.08) 

as  bright  sunshine;  (2)  GAnGS  and  SPATE  use  a  visual  hash 
function  for  users  to  perform  comparison  of  the  hash  values 
-  such  a  visual  hash  cannot  support  remote  execution  and 
enables  users  to  simply  click  “match”  without  actually  per¬ 
forming  the  comparison;  (3)  GAnGS  and  SPATE  enable  by¬ 
standers  to  learn  everyone’s  contact  information,  potentially 
disclosing  sensitive  private  information.  We  believe  that  the 
improvements  that  SafeSlinger  offers  are  significant  enough 
that  it  is  now  ready  for  wide-spread  adoption.  In  particular, 
the  privacy  protection  achieved  with  the  group  DH  protocol 
is  critical  for  people  who  want  to  protect  their  privacy.  Ho- 
Po  Key  [30]  key  establishment  is  useful  for  large  groups, 
requiring  people  to  form  a  physical  ring  in  space  to  avoid 
counting  while  detecting  Sybil  and  other  attacks.  SafeSlin¬ 
ger  uses  Ho-Po  Keys  when  users  indicate  a  large  group  size. 

Nithyanand  et  al.  recently  studied  the  usability  of  secure 
group  association  protocols  [32].  Their  results  with  real  user 
studies  concludes  that  the  ideal  group  credential  exchange 
protocol  does  not  use  a  leader  (i.e.,  is  peer-based),  requires 
users  to  count  and  input  the  number  of  participants,  and  re¬ 
quires  users  to  verify  Short  Authentication  Strings  (SAS). 
Hence,  their  study  confirms  the  approaches  we  have  selected 
for  SafeSlinger. 

PGP  key-signing  parties  [4]  enable  users  to  obtain  each 
other’s  public  key,  but  they  are  cumbersome  for  participants. 
SafeSlinger  can  be  viewed  as  a  more  modern  and  usable  ap¬ 
proach  using  smartphones  to  securely  exchange  public  keys. 

Many  researchers  have  studied  device  pairing  or  key  setup 
between  two  devices  [3,  5-7,  12,  13,  21,  24-26,  28,  35,  38]. 
These  systems,  however,  do  not  easily  generalize  to  multiple 
parties,  as  they  would  encounter  the  issues  we  describe  in 
Section  4. 

10.  LIMITATIONS  AND  RESEARCH  CHAL¬ 
LENGES 

The  main  limitations  of  the  current  SafeSlinger  applica¬ 
tion  are:  (1)  its  reliance  on  users  to  diligently  perform  the 
world-list  comparisons,  thereby  ensuring  that  all  users  have 
the  same  hash  value,  and  (2)  its  requirement  that  users  check 
the  received  contact  list  entries  before  finally  importing  them 
into  their  address  book.  Although  SafeSlinger  is  more  usable 
and  secure  than  all  prior  work  that  we  are  aware  of,  it  is  an 
open  research  problem  to  determine  whether  the  reliance  on 
the  user  can  be  further  reduced  without  requiring  additional 
trust  assumptions  on  other  users.  Another  research  challenge 
is  a  formal  verification  of  the  protocol  that  includes  user  ac¬ 


tions,  which  may  help  in  exploring  optimizations  that  limit 
reliance  on  the  user. 

11.  CONCLUSION 

To  realize  the  vision  of  secure  online  communication,  we 
need  to  overcome  several  human  challenges:  some  users  are 
ambivalent  about  security  or  privacy,  most  users  lack  secu¬ 
rity  expertise,  and  many  users  prefer  convenience  over  secu¬ 
rity  and  may  not  want  to  expend  much  effort  for  security. 

To  counteract  these  challenges,  we  designed  SafeSlinger 
as  an  easy-to-use  application  that  offers  many  benefits  to 
drive  usage.  Per  Metcalfe’s  law,  the  utility  of  a  system  grows 
with  the  square  of  the  number  of  users.  Our  goal  is  thus  to 
provide  immediate  utility  to  enable  epidemic  growth. 

We  achieve  immediate  utility  through  the  robust  exchange 
of  contact  list  information  between  different  smartphone  plat¬ 
forms,  which  does  not  require  any  location  information  or 
leak  private  information  outside  the  participating  phones. 
SafeSlinger  also  provides  simple  and  secure  messaging  and 
file  transfer  that  is  immediately  usable.  Because  the  mes¬ 
sages  are  encrypted  and  require  a  password  to  access,  many 
teens  may  find  this  appealing  to  protect  their  messages  from 
peers  and  parents. 

To  seed  epidemic  growth,  SafeSlinger  supports  secure  re¬ 
mote  exchange  of  contact  list  information  and  secure  intro¬ 
ductions,  where  a  common  friend  can  securely  sling  respec¬ 
tive  contact  list  information  between  two  users,  setting  up  a 
secure  channel  between  them. 

Through  free  multi-platform  applications  available  on  smart¬ 
phone  markets,13  open  documentation,  and  open-source  code, 
we  anticipate  wide  adoption  of  SafeSlinger.  Assuming  wide 
adoption,  we  hope  to  provide  usable  and  secure  communica¬ 
tion  for  the  masses,  and  a  security  platform  that  will  enable 
numerous  security  services  and  applications. 
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